Real-Time Streaming Protocol (RTSP) traffic typically utilizes a number of different protocols such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), the Real-Time Transport Protocol (RTP) and the RTP Real-Time Control Protocol (RTCP). In particular, a single RTSP session typically includes five network channels: (i) a control channel formed by a TCP connection between a client and a server, (ii) a video channel formed by a flow of UDP packets in RTP format with encoded moving images from the server to the client, (iii) an audio channel formed by a flow of UDP packets in RTP format with encoded sound from the server to the client, (iv) a video feedback channel formed by a flow of UDP packets in RTCP format with video stream control information from the client to the server, and (v) an audio feedback channel formed by a flow of UDP packets in RTCP format with audio stream control information from the client to the server.
Suppose that a client on the Internet obtains streaming data from a server in a local area network (LAN) through a conventional gateway (or router) using RTSP. Furthermore, suppose that this gateway is configured for Network Address Translation (NAT). To this end, the client on the Internet initiates an RTSP session by sending a packet (i.e., a “SYN” packet) to the gateway's Internet Protocol (IP) address. The gateway receives the packet, and adds an entry to its NAT table so that it can direct the packet from the client on the Internet to the server in the LAN and vice versa through the TCP connection. The gateway then sends the packet to the server. At this point, the gateway can properly direct subsequent packets sent through the TCP connection between the client and the server using the configured NAT table, e.g., control packets exchanged between the server and the client when negotiating port numbers for the UDP channels.
In addition to the TCP connection, the RTSP session requires a video channel for streaming video content and an audio channel for streaming audio content from the server to the client. In a similar manner to that described above for establishing the TCP connection, the gateway receives a video channel UDP packet from the server on its way to the client (in accordance with RTP), configures its NAT table (e.g., in preparation for any response packets coming back from the client) and sends that packet onto the client. Additionally, the gateway receives an audio channel UDP packet from the server, configures its NAT table and sends that packet onto the client.
The RTSP session also requires a video control channel and an audio control channel from the client to the server. For the video control channel, the gateway receives a video control UDP channel packet (in accordance with RTCP), and configures its NAT table to properly direct that video control channel UDP packet and future video control UDP channel packets from the client to the server. Similarly, for the audio control channel, the gateway receives an audio control UDP channel packet, and configures its NAT table to properly direct that audio control channel UDP packet and future audio control UDP channel packets from the client to the server. The gateway then conveys UDP packets on the video control channel and on the audio control channel from the client to the server.
As briefly mentioned above, the port numbers for the four UDP channels (i.e., the video channel, the audio channel, the video control channel and the audio control channel) are selected dynamically. In particular, the server and the client negotiate the actual UDP port numbers through the TCP connection. In accordance with RTSP, the UDP port numbers for the video control channel and the audio control channel are one more than the UDP port numbers for the video channel and the audio channel. That is, if the video channel uses port number Y, the video control channel uses port number Y+1. Similarly, if the audio channel uses port number Z, the audio control channel uses port number Z+1.
As the RTSP session continues, the gateway translates addresses so that TCP and UDP packets delivered to the client appear to have originated from the gateway. Accordingly, the gateway is considered to be a proxy for the server, i.e., a reverse proxy. Later, when the gateway observes tearing down of the TCP connection, the gateway typically adjusts the NAT table (i.e., deletes the NAT table entries) to disable NAT for the TCP connection.
In some situations, there may be multiple servers in order to increase server capacity. In such situations, the conventional gateway can be configured to handle RTSP traffic by selecting among the multiple servers for load balancing purposes. Here, the gateway is essentially a reverse proxy operating on behalf of the multiple servers, i.e., a front-end to the multiple servers making those servers appear to be at a single IP address on the Internet.